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i Remarks 

* 

Status of the Claims 

Claims 1-31 are pending in the application. All claims stand rejected. By this 
paper, claims 1, 8, 18 f 27, 29, and 30 have been amended. Reconsideration of all 
pending claims herein is respectfully requested. 

Interview 

The applicant wishes to thank the Examiner for the courtesy of the telephone 
interview on December 1, 2005. The applicant has made the changes that the 
Examiner suggested would overcome the art of record, but understands that the 
Examiner will perform a follow-up search. 

Claim Refections 

Claims 1, 8, 12, and 29 were rejected under 35 U.S.C. 102(e) as being 
anticipated by U.S. Patent No. 6,269,078 to Lakshman et al. ("Laksham"). Claims 2- 
7, 9-11, 13-17, and 27-28 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Lakshman in view of Ito et al. ("Ito"). Claims 18, 21-22, and 26 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Lakshman in view 
of Humpleman. Claims 19-20 and 23-25 were rejected under 35 U.S.C. 103(a) as 
being unpatentable over Lakshman et al in view of Humpleman and further in view of 
Ito. These rejections are respectfully traversed. 

The claimed invention allows a media server to more efficiently serve 
multimedia programs to multimedia nodes in a bandwidth-limited network. For 
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example, a wireless home network with a maximum bandwidth of 54 Mbps may be 
limited to only two or three multimedia nodes if the bandwidth is equally distributed 
between the nodes. However, in practice, multimedia programs do not always 
require the same amount of bandwidth at any given time. For example, in video, 
scenes with a high degree of movement require greater bandwidth than static 
scenes. This creates bitrate peaks or spikes, which are significantly higher than the 
average bitrate. 

In accordance with the claimed invention, a media server is able to take into 
account the bandwidth requirements for each requested media program and adjust 
the relative amount of bandwidth allocated to the requesting nodes, allowing the 
media server to potentially accommodate additional nodes. For example, each node 
may be initially allocated an amount of bandwidth that is less than what is required to 
handle bitrate spikes for a requested media program. However, prior to spike 
occurring, the media server may temporarily increase the bandwidth allocation to a 
particular node, allowing it to buffer a sufficient amount of data to accommodate the 
spike. 

However, this type of bandwidth reallocation requires the media server to 
know, at any given time, the bandwidth requirements for each media program being 
transmitted to a respective node. Indeed, the media server needs to anticipate a 
bitrate spike for a particular media program well in advance in order to compensate 
for it. The amount of lead time necessary to reallocate bandwidth and prefill buffers 
is directly related to how "tight" the bandwidth constraints are. For example, in order 
maximize bandwidth usage among several multimedia nodes, the multimedia server 
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may need i to know about upcoming bandwidth spikes that won't occur for several 
minutes in order to provide time to prefill the buffers at the receiving node. 

Conventionally, advance knowledge about bandwidth spikes has been 
unavailable because media servers have not previously generated and stored bitrate 
histograms for entire media programs. As a result, media: servers have been 
required to "estimate" or "predict" how much bandwidth is required, typically on the 
basis of the past requirements or forecasting models. This, however, often results in 
buffer underruns, which cause video and audio degradation, when predictions prove 
to be inaccurate. 

1. Lakshman Merely "Predicts" But Does Not "Know" the Bandwidth 
Requirements for a Particular Media Program to be Transmitted 

Lakshman could not be more different from the claimed invention. Rather than 

knowing the amount of bandwidth required at any given time for a particular media 

program based on a "previously-generated" bitrate histogram, as in the claimed 

invention, Lakkshman is limited to "predicting" bandwidth requirements. 

• Lakshman uses a "mechanism for predicting demands to be made of the 
network based on the character of the video information which is to be 
encoded in the future" Col. 5, lines 2-4 (emphasis added). 

m "Having considered the active and inactive sources and their 
characteristics, it is thus possible [for Lakshman] to model and thus predict 
what cell rate needs will be for an encoder based on the types of video to 
be transmitted." CoL 10, lines 13-16 emphasis added, quoted by 
Examiner). 

• "The forecasting can be done using the source model developed in the 
Heyman article." Col. 9, lines 60-61 (emphasis added). 
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• tt [l]n video teleconferences, I frames can be modeled by a Marcov chair* 
with a DAR (1) transition matrix similar to that used for a video 
teleconference." (emphasis added). 

• "Having discussed the techniques for predicting a demand including the 
timing for such a prediction and the smoothing out of the request or 
demand based on predictions over a window of frames, it Is appropriate to 
consider how the network treats the demand and how the encoder adapts 
to the response from the network." Col. 11, lines 12-16 (emphasis added). ■ 

As described with respect to FIG. 5, Lakshman's encoder predicts (501 ) the need for 

rate allocation for future frames and provides (502) the predicated rate to a network. 

The network allocates (504) bandwidth in response to the request and advises (504)* 

the source of an explicit rate based on the actual available bandwidth. The encoder 

at the source then adjusts (505) the current rate based on the advised explicit rate. 

Lakshman's system is designed to work with video that has not yet been 

encoded, such as video conferences. See col. 5, lines 3-4 ("video information which 

is to be encoded in the future")', col. 4, lines 1-4 ("the present invention provides a 

new method and system for transporting compressed video that provides feedback 

control of the encoding rate"). Based on models of typical "types of video to be 

transmitted" (col. 10, line 16), Lakshman can only predict what the bandwidth 

demand for an actual media program might be_ Indeed, the Examiner admits that 

"[information illustrated by the histogram of Figure 6A is used in the forecasting 

models: 1 Office Action at page 3 (emphasis added). Mathematical models, as of the 

type described in Lakshman (cols. 7-10), are not "bitrate histograms" for particular 

media programs, as claimed. They are based on "studied sequence[s]" of data, as 

shown in the "histogram" of FIG. 6A. See col. 9, lines 47-50. 
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s By contrast, there is no need to "predict"* bandwidth requirements in the 

■' claimed invention. The claimed invention does not "forecast" bitrate requirements, 
nor does it rely on "models." Because the claimed media programs are "previously- 
j encoded," such as a DVD or other existing media program, the system is able to 
generate a bitrate histogram of the program by which its actual bitrate requirements 
at "any given time" may be known (not predicted). The claimed invention does not 
"adjust" the encoding rate, which is contrary to the whole point of Lakshman, See 
col. 4, lines 1-4 ("the present invention provides a new method and system for 
transporting compressed video that provides feedback control of the encoding rate*). 

In response to the foregoing argument in the applicant's prior response, the 
Examiner argued that the "features upon which applicant relies (i.e., claimed 
invention conclusively knowing .the bitrate) are not recited In the rejected claim(s). 
Office Action at page 2. However, the applicant respectfully submits that a 
"previously-generated histogram of bitrate as a function of time," which exists prior to 
transmission of the media program, and which is identified prior to transmission for 
purposes of anticipating a future bitrate spike, is the very definition of "conclusively 
knowing the bitrate." A system that can Identify a "histogram of bitrate of a function of 
time for a media program" inherently "knows" the bitrate-for the media program at any 
given time, as contrasted with Lakshman's mere prediction. 

While the applicant believes that the original claim language clearly 
distinguishes over Lakshman, the applicant has amended the independent claims to 
recite: "each bitrate histogram indicating actual bitrate requirements for every given 
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point of time within -the associated multimedia program," an " actual bitrate spike," 
" actual changes in bitrate requirements," and the like. r 

2. Lakshman Does Not Disclose a Histogram of Bitrate as a Function of Time 
Indicating Bitrate Requirements at Every Given Point of Time Within the > Associated 
Multimedia Program 

The applicant respectfully submits that Fig. 6A of Lakshman is not the claimed 
"histogram of bitrate as a function of time" as suggested in the Office Action. Rather, 
it is a histogram of the "frequency" with which a particular number of "cells per frame" 
occurs within a "studied sequenced The number of cells per frame does not 
determine the frame rate. Indeed, the frame rate is determined by specific standards 
for a particular medium, e.g., 30 frames per second for TV. Fig. 6A is completely 
lacking in a time axis, which could be used to identify when bitrate spikes occur within 
a particular media program. 

The Examiner responded to the applicant's argument that there is no time axis 
by stating that the "cell rate per frame is a function of time because video inherently 
ps] related to time (frames per second)/ Office Action at page 2. However, this 
completely ignores the claimed limitation of "function of time," and completely ignores 
the figure, which does not include a time dimension. 

While video is sometimes expressed in "frames" per second, the histogram of 
FIG. 6A does not show this, yet the Examiner argues that Lakshman's histogram is 
identical to the claimed histogram under 102(e). An anticipation under section 102 is 
proper only if the reference shows exactly what Is claimed. Titanium Metals Com, v. 
Banner . 778 F.2d 775, 780 (Fed. Cir. 1985); MPEP § 2131. In this case, no one of 
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J ordinary skill in the art would reasonably sargue that FIG. 6A shows a histogram of 

r bitrate "as a function of time." r 

Accordingly, Lakshrnan's histogram is completely unable to perform its 

! claimed purpose, i.e., allowing a media server to anticipate the precise point in time 

at which a bitrate spike occurs. Knowing the temporal location of the bitrate spike, 
the server may compensate for it by changing bandwidth allocations. 

With regard to FIG. 6A of Lakshman, of what possible use would it be to know 
there were a total of 1000 occurrences of frames that include 100 cells? This does 
not say when such an event occurred. It cannot be used to anticipate bitrate spikes. 
The applicant respectfully asks the Examiner how the "temporal characteristic" 
(location of a bitrate spike) can be identified from FIG. 6A, as suggested at page 4 of 
the Office Action. . 

Notwithstanding the foregoing, the applicants have amended claim 1 to recite 
that "each bitrate histogram [indicates] actual bitrate requirements at every given 
point of time within the associated multimedia program." Thus, the bitrate histogram 
serves as a temporal "map" of bitrate fluctuations, allowing the server to anticipate 
and compensate for bitrate spikes. Even if the prior language was debatable, the 
amended language is not. Lakshman does not disclose or suggest a histogram of 
bitrate as a function of time that indicates "bitrate requirements at every given point in 
time within the associated multimedia program." 

The addition of Ito does not cure the deficiencies of Lakshman. Ito does not 
disclose bitrate histograms. Rather, Ito's video data index includes instructions for 
how to extract certain frames of video data to achieve one of several different bitrates 

17 

PAGE 23/29 * RCVD AT 12/1/2005 6:00:20 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-6/26 * DNES:2738300 * CS1D:801 578 6999 * DURATION (mm-ss):06-24 



12/01/2005 16:04 FAX£801 578 6999 



STOEL RIVES 



@024 



depending^on the network load. In other words, if the network load won't permit the 
transmission of full 1.5 Mbps video data, Ito's server degrades: the video quality, as 
instructed in the video. data index, by selecting some frames and dropping others. 

The addition of Humpleman does not cure the deficiencies of Ito and 
Lakshman. Humpleman merely discloses a home network system that provides 
browser-based command and control. Nothing in Humpleman suggests the claimed 
bitrate histogram. Furthermore, nothing in Humpleman suggests modifying a 
bandwidth allocation in anticipation of a bitrate spike indicated within a bitrate 
histogram. 

Because the cited references fail to disclose the limitations of claim 1 , they 
cannot anticipate claim 1. Anticipation under section 102 is proper only if the 
reference shows exactly what is claimed. Titanium Metals Corp. v. Banner , 778 F.2d 
775, 780, 227 USPQ 773, 777 (Fed. Cir 1985); MPEP § 2131.01. The applicant 
respectfully submits that claim 1 is patentably distinct over the cited references. 
Claims 2-7 depend directly or indirectly from claim 1 and are thus believed to be 
patentably distinct for at least the same reasons. 

Claim 8 recites dynamically adjusting said first amount of bandwidth based on 
a previously-generated template of bitrate data as a function of time. As explained 
above, Lakshman does not disclose a template of bitrate as a function of time that 
indicates actual bitrate requirements for every given point in time within a multimedia 
program to be transmitted. Furthermore, Lakshman does not disclose a previously- 
generated histogram of bitrate as a function of time associated with a previously- 
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encoded multimedia program. Accordingly, claim 8 is also believed to be patentably j ~. 
distinct. 

3. The References Do Not Disclose or Suggest Modifying the Bandwidth 
Allocation of a First Multimedia Node Based on the Bitrate Histogram of a Program 
Being Sent to a Second Multimedia Node \ 

Claim 12 recites "dynamically adjusting said first amount of bandwidth based : 
on a template of bitrate data as a function of time indicating changes In bltrate 
requirements of a multimedia program requested by a second multimedia node ." j 

The applicant respectfully points out that the Office Action completely fails to 
address the claimed limitation. The rejection on page 6 misquotes the claim, 
dropping the phrase " reouested bv a second multimedia node ." 

The ability to alter the bandwidth allocation of a first multimedia node based 
On a bitrate histogram of a program being sent to a second multimedia node is not 
taught or even suggested by the references. Even rf all of the Examiner's arguments 
are correct, the references would only teach altering the bandwidth allocation of a 
first multimedia node based on a bitrate histogram of program being sent to the first 
multimedia node, Lakshman looks at a program being sent to a multimedia node in 
isolation. There is no hint that Lakshman allows the bandwidth allocation for a 
multimedia node to be altered based on a bitrate histogram for a program other than 
the program being received by that node. \ 

Likewise, claim 29 further recites "identifying a second stored bitrate histogram \ 
associated with a second multimedia program to be transmitted to a second i 
multimedia node, the second bitrate histogram indicating a future spike in bandwidth i 
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requirements for the second multimedia program* and throttling back the bandwidth 
allocated to the first multimedia program just prior to. encountering the bandwidth 
spike associated with the second multimedia program at a time sufficient to fill a 
buffer of the first multimedia node." The applicant respectfully submits that none of 
the cited references disclose throttling back bandwidth pf a first multimedia program 
based on an anticipated spike in the bandwidth requirements of a second multimedia 
program as indicated by a bitrate histogram for the second multimedia program. 



4. The Office Action Does Not Address the Specific Limitations of Claim 30 

As amended, claim 30 recites a method comprising: 

generating a histogram of bitrate as a function of time for an entire 
media program before a transmission thereof to a multimedia node, the bitrate 
histogram indicating bitrate requirements at every given point of time within the 
associated media program; 

allocating a first amount of network bandwidth for transmitting the 
media program to the multimedia node, the first amount being a subset of 
available network bandwidth to the multimedia node; 

identifying, during transmission of the multimedia program, an actual 
upcoming bitrate spike within the bitrate histogram for the multimedia program, 
the actual bitrate spike temporarily requiring more than the available network 
bandwidth for transmission of the multimedia program; and 

temporarily increasing the bandwidth allocation for the multimedia 
node from the first amount to a second amount in anticipation of the actual 
bitrate spike indicated in the bitrate histogram, the temporarily increased 
bandwidth allocation being sufficient to fill a buffer at the multimedia node to 
avoid a buffer underrtin at the multimedia node during the actual bitrate spike. 

Although listed among the 35 U.S.C. 103(a) rejections, the claim is discussed 

very briefly in connection with the 35 U.S.C. 102(e): rejections. Accordingly, the 

applicant respectfully requests clarification as to the correct basis for rejection. 
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* The entire treatment of claims 30 and 31 in the Office Action is as follows: 

"Claims 30-31 are met by that discussed above for; claims 1 , 8, and 29. The 

information represented by the histogram of Figure 6AMs generated for determining 

the necessary bandwidth." Office Action at page 8. However, this ignores several 

t 

limitations that are found only in claim 30- t 

For example, unlike the claimed invention, Lakshman does not generate a 
histogram of bitrate as a function of time for an entire multimedia program before 
transmission thereof to a multimedia node. As noted^ above, Lakshman relates to 

video that has not yet been encoded, such as in a video conference. Col. 9, lines 64- 

l 

67. Hence, Lakshman cannot generate a histogram for[an entire multimedia program 
before it is transmitted to the multimedia node. As noted above, the "histogram" of 
FIG. 6A is not a histogram of a particular program to bfe transmitted to a multimedia 1 
node. Rather, it is a "studied sequence" used to develop a mathematical model for 

predicting demand during transmission of a particular "type" of multimedia data. 

\ 

Lakshman also does not perform the step of "identifying, during transmission 
of the multimedia program, an actual bitrate spike within the bftrate histogram for the 

F 

multimedia program, the actual bitrate spike temporarily requiring more than the 

\ 

available network bandwidth for transmission off the multimedia program." 

i 
i 

Lakshman's "histogram" does not allow a server to identify an upcoming bitrate spike 

during transmission of an associated media program. : His "histogram" merely says, 

i 

for example, that there were a total of 1000 occurrences of frames that include 100 

t 

cells, and is not even specific a particular media program to be transmitted, as 
previously explained. i 
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Moreover, Lakshman does not temporarily increase a program's bandwidth 
allocation in anticipation of the actual bitrate spike indicated in a bitrate histogram to 

l; 

r 

fill a buffer at the multimedia node to avoid a buffer underrun during the future bitrate 
spike. At best, i Lakshman only predicts (501) the need for rate allocation for future 
frames and provides (502) the predicated rate to a network. The network allocates 
(504) bandwidth in response to the request and advises (504) the source of an 
explicft rate based on the actual available bandwidth.! The encoder at the source 

then adjusts (505) the current rate based on the advised explicit rate: The fact that 

i 

Lakshman's encoder adjusts the encoding rate clearly shows that the media program 
has not yet been encoded, contrary to the claimed invention. 

. Also, adjusting the encoder means reducing quality where insufficient 

bandwidth exists to transmit the media program. This is completely different from the 

i 

claimed process of temporarily manipulating the bandwidth allocation based on 
foreknowledge of upcoming bitrate spikes so that the fnedia program is transmitted 
with perfect quality. In such cases, Lakshman always results in quality loss, whereas 

i 

the claimed invention preserves quality. t 

In view of the foregoing, the applicant respectfully submits that claims 1-31 , as 
amended, are patentably distinct over the cited references, alone or in combination. 

i 

A Notice of Allowance is respectfully requested. If ^ny issues remain after this 

\ 

response, the Examiner is invited to contact the undersigned at: the telephone 



number provided below. 
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Respectfully subrriitted, 



Digeo, Inc 




Cory D. Christpnsen 
Registration Np. 43,548 



STOEL RIVES LLP 

One Utah Center Suite 11 00 

201 S Main Street 

Salt Lake City, UT 841 1 1-4904 

Telephone: (801)328-3131 

Facsimile: (801)578-6999 
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